Casey’s Contraptions And The IGF

Today is the day! We finally announced my next game: Casey’s Contraptions.

This is a bit of a different project than some of my past ones. This one is a collaboration with Miguel Ãngel Friginal from Mystery Coconut. I’m doing the programming, Miguel is doing all the art, and we’re both contributing equally to the design and everything else. It has been great having some awesome art to go with the game, but also to collaborate with someone really closely on the game.

Casey’s Contraptions was one of those ideas for a game that I kept wanting to make for quite a while, and now it was finally the right time. It meets the three main requirements that I’m looking for in a game project:

Something original
Has potential to sell well
It involves a creative activity (instead of something violent or destructive)

The idea of games based on mechanical contraptions is not new, but there are surprisingly few games based on it. We are hoping to bring a lot new to the table: Casey himself, unlockable items, interface built from the ground up for multi touch, modern physics simulation, social features, sharing of solutions, and even creation and sharing of new levels. We are really excited to be working on this project and we can’t wait until it’s released.

Development

Casey’s Contraptions started as a prototype back in the summer. After a day or two messing with physics engines and creating some objects, I knew there was something there, so I spent a two more weeks creating an initial version. It wasn’t much more than a tech proof-of-concept, but it was clear that there was a game there (even with my horrible stand-in clip art assets).

I sent that built to a couple of friends for initial feedback. It was laughably early, but that’s the time when it’s possible to really make radical changes to the design. I knew the people I was sending it to a) were used to seeing games at early stages, and b) were not afraid to tell me if something sucked. Actually, I told them to skip the nice parts and just focus on everything that they didn’t like. Not surprisingly, that initial feedback was crucial, and really shaped how Casey’s Contraptions evolved since then.

Shortly after that, Miguel joined me full time on the game and we dove right into it. For our development, we used a super light-weight agile approach: We have high-level “user stories”, and two week iterations. Iterations are somewhat flexible (plus minus a few days) and we don’t strictly estimate the tasks, just take on as many user stories as we think we can do in that time. The important parts are to always be focused on the most important stories, and to take them to completion each time.

Miguel lives in Seattle and I’m in Carlsbad, so we do all of our work remotely. We use Subversion hosted remotely, and we’re in constant communication through iChat and email. That allows us to iterate on a piece of art, an item behavior, or a menu item multiple times very quickly. It’s not as good as sitting side by side, but I haven’t felt like working remotely has gotten in the way at all.

After a busy month and a half, we got to where you see it today, and we submitted the game to the Independent Games Festival (IGF).

Independent Games Festival

Some people have asked me why I wanted to submit it to the IGF. I have to be honest and admit that I had never really considered not submitting it.

I imagine everybody reading this blog knows about the IGF already. It’s the closest thing to the Movie Academy Awards that we have for independent games. There are many reasons why you’d want to submit your game. The amount of press and prestige associated with winning or even being nominated as a finalist is huge. The prize money is a nice touch, but it’s not really enough to make much of a difference in the game itself (I’m talking about the Mobile Category prize). Of course, there are many other fantastic games that are competing at the IGF (a total of almost 400 games!), so it’s hard to count on becoming a finalist.

One very real and concrete reason to enter the IGF was to have a very well-defined milestone. It wasn’t that different from one of our iterations, except that we had a real customer (the IGF judges) and a non-flexible deadline. That made us really focus our efforts and put in some extra effort in the last couple of weeks to get it in shape for the IGF. Looking back at the game just a couple of weeks ago, it’s amazing how far it came in that time.

For me personally, the biggest reason to enter the IGF is because it’s something I’ve always wanted to do. I’ve followed the IGF since the first one in 1999 (which was, coincidentally, the first GDC I attended). Every time I walked through the booths or watched the award ceremony, I wanted to be part of it. So finally, this was my chance to do it. It was a great experience going through the process. Now the next life goal will be to actually make it as a finalist.

Submitting Casey’s Contraptions had another, unexpected side effect: It tipped our hand and forced us to announce the game sooner than we were planning on doing. It wasn’t until a few days before the submission that we realized the list of IGF games would go public right away. Originally we were planning on announcing the game at 360iDev in mid November, but this forced us to move the schedule up somewhat. Hopefully that will be a good thing and will allow us to build some good buzz in the upcoming months all the way until the release. Keep an eye out for a gameplay video and some hands-on previews in the next few weeks.

If you want to keep up to date with Casey’s Contraptions development, join the Facebook group, follow Miguel and me on Twitter, or keep an eye on the Touch Arcade thread.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Indie Project Management For One: Tools

I’ve been making computer games in some form or another for just over 25 years now. At the very beginning, as a hobby (passion) and completely by myself (although not for lack of trying to get some of my friends involved). In the late 90s, when I finally left academia and started making games professionally, teams were still relatively small, with a total of around 10-15 people per team. As we all know, budgets and scopes kept growing, and so did team sizes. At its peak, the largest team I worked at had around 200 people. That’s when I decided to go indie and started Power of Two Games, which was obviously just two of us. Finally, now as Snappy Touch, I’ve gone full circle: It’s just me again.

Development tools and hardware have changed quite a bit from the times I was writing in straight Z80 assembly and saving the programs to a tape. But I’ve also changed and learned a lot during all those years developing games, and even though I’m writing games by myself again, I’m doing things very differently from how I did them back at the start.

One thing that I’ve always done is to question everything. Why should I do things a certain way? Why is that the “accepted” way of doing something? And not surprisingly, at each step of the way, I’ve changed my development style to match my situation (often in ways that went against the “common wisdom”).

When it comes to solo development, I rely heavily on the concept of goals and iterations at multiple levels:

Immediate (< 1 minute): Prioritizing the ideas going through my mind. Writing tests. Writing code.
Short Range (< few hours): Tasks that move the project forward in some way.
Mid Range (< 2 weeks): “Stories” that define a self-contained, significant part of the project.
Long Range (full project, several months): Ship date, beta testing, etc.

It turns out, I use a different set of tools to help me manage the items at each level of the development cycle.

Immediate

These are the actions I take and complete in less than a minute or two. Most of them are writing tests (with UnitTest++, of course), writing code to make those tests pass, refactor code, and check it into Subversion. I have my Subversion repository hosted on Dreamhost and I access it through SSH so it’s secure, accessible from anywhere with an internet connection (or 3G signal and HandyLight), offsite, and easy to backup. And because Subversion works great offline (unlike Perforce), it’s not a problem to work without connection to the repository for a while.

I also need to manage my minute-to-minute thoughts, write down ideas and reprioritize them when the time comes. When I’m “in the zone”, I get way more ideas than I can execute with my fingers: This function needs to be moved to a different file, I really should be compacting that data over there, who was stupid enough to name this file this way?, that variable shouldn’t be cached, etc. If I don’t write things down, I will either forget them, or I’ll stress for hours until I finally get around to doing them. I could also do things as I think about them, but then I would be chasing a rabbit down a neverending hole and wouldn’t get any work done (I’m sure anybody who’s gotten lost browsing web pages can identify with that).

I used to do this the old-fashioned way, simply with paper and pencil (like Bob described in his blog post). However, I found that physical paper and pencil was just too limiting: I can type a lot faster than I can write, switching to writing requires moving away from the keyboard, and, most importantly, I need to bring the notes with me everywhere and it’s very difficult to rearrange, sort, or coalesce them in any way.

So instead, my tool of choice these days is JustNotes. It’s perfect for jotting down thoughts in a matter of seconds without even interrupting my train of thought. I have JustNotes bound to a global key, so in the middle of typing a line of code, I can press that key, enter whatever I’m thinking about, press the key again, and finish the line of code. All in 4-5 seconds. Don’t laugh: The fact that I can do that in just a few seconds without moving my hands away from the keyboard means I can use it any time without much penalty. It’s amazing how many things I jot down that I wouldn’t do otherwise.

Short Range

To manage tasks up to a few hours in length, I use Trac. Trac is a fantastic issue-tracking tool: It’s free, it’s fast, it’s simple, and it’s configurable. In the past I’ve used anything from spreadsheets, to Bugzilla, to publisher-owned bug databases, and nothing comes close to Trac for my needs. It also scales very well to teams of more than one person (although it might not be good enough for hundreds of people).

Just like Subversion, I have Trac hosted externally, through my web hosting company. Sometimes it’s frustrating if I need to access it and the server is down, but again, the convenience of having it off site makes it well-worth it.

Any task that requires more than 10-15 minutes goes in Trac, and then I can easily prioritize tasks depending on their importance. Usually, if an item has been on my instant queue in JustNotes for about a day and I haven’t gotten around to it, it either gets deleted or it gets moved into a full item in Trac. The only way progress happens is by ticking off Trac tasks. In the end, my projects live and die by Trac.

Medium Range

User stories (to borrow terminology from Scrum/XP) are visible, relatively self-contained features of the final project. They’re made up of several tasks, and usually take a few days to a few weeks to implement. A group of user stories make up a full iteration (sprint) of the game, which is usually between one and two weeks long. Sometimes user stories are complex enough (add a replay feature visible on the web site) that the full iteration is just the one user story.

I keep track of these stories in Trac as well. Trac is both an issue-tracking system and a wiki, so the wiki part is perfect to keep these user stories. In addition to that, I label tasks as belonging o a particular iteration. That allows me to separate what needs to be done for this iteration, from other tasks that I added for the future. At the start of each iteration, I decide on the user stories and either generate new tasks or label existing tasks as due for this iteration.

The wiki in Trac is extremely valuable for all sorts of other things: game design ideas, general brainstorming, gathering reference material, etc.

Trac ends up being the perfect mid-range vision of my project.

Long Range

User stories and tasks in Trac aren’t enough to cover a project that is potentially 3-4 months long. I need something that helps me with the longer view, otherwise I find that things creep up on me without realizing it because I’m so focused on the short and mid-range items.

The best tool I’ve found so far is very low-tech: A printable month-per-page calendar covering the full length of the project. Right now I’m shooting for a November release of my current project, so I printed August, September, October, and November and pinned them to the corkboard on my office. It’s amazing the sense of urgency that seeing your ship date gives you. You realize that you only have a handful of weeks before shipping and makes it much easier to prioritize tasks (and chop off features or save them for an update).

I realize this long-term, calendar view isn’t very useful if you don’t have a set release date and you want to continue chipping at your game until it’s ready. But even if your release date is flexible, having this long-term view can help you keep budgets in perspective and manage them accordingly.

Finally, for an extra bit of motivation (or maybe this falls in the category of excessive pressure), I just started using a countdown widget for the Mac OS Dashboard. Just in case the calendar view wasn’t enough, here’s a countdown (down to the second) of the time left until release.

Speaking of which, I think it’s time I get back to work. Only 102 days left!

No Rest for The Indies

You’d think that things would slow down around Christmas time over here. And that I would have lots of time to catch up and write about all the things I keep jotting down in my overflowing “to write” list. Right? Unfortunately that’s not the case.

I do want to catch up and share my iPhone development experience with everybody, but it’s hard to make time, even during the holidays. To make things worse, I have a pretty hard deadline I set myself to have my iPhone app ready by early February.

It’s funny, I’ve worked more hours in the last year than any other year during my career, but it has never felt like work. Quite the opposite actually, and I find myself doing “work” instead of other things that used to be more fun and having a blast with it. For example, my game-playing time has gone waaay down. If I have an hour that I can do anything, I think “oh, maybe I can play a bit of World of Warcraft now” followed by “but it would be so much fun to finally add this other feature…” I let you figure out which one ends up winning in the end. If it wasn’t because of my weekly WoW session with Jim, Joey, and Michael, I wouldn’t make any progress in the game!

Not only am I enjoying what I do immensely, but it’s very easy to spend lots of time doing it because I get to do it from the comfort of my own home. I never have to worry about getting to work by a particular time, so I can get in my morning runs or go grocery shopping when the stores are empty, I have all my stuff around me, my work area has an incredible view overlooking the whole of Mission Valley, and my kitchen is stocked up with all my favorite teas. It’s really easy to spend hours and hours working. A bit too easy actually.

Burnout is the evil flip side of fun work. Even with incredibly rewarding and fun work, doing something for many hours a day can burn me out pretty easily. The symptoms are obvious: I start to lose interest, I’m not as productive, my mind wanders, and I find all sorts of other things I’d rather be doing. Fortunately, I can recognize those symptoms early on, so just backing off a bit, or taking an afternoon off, allows me to walk the fine line between work and burnout and keeps me productive.

Initially I was a bit concerned about the thought of working full time from home. Would I miss the interaction with coworkers and the sparks and new ideas from seeing all sorts of stuff around me in a company. It turns out that it wasn’t anything to be worried about. Thanks to the Internet, it’s very easy to reach out and connect with other people. I regularly share my progress with some friends and family members, and I always enjoy hearing their comments and reactions (even the not so positive ones–especially those actually). I also meet in a semi-regularly basis with my friend Dave, who is doing all the graphic design for my app (and he’s the mastermind behind the Power of Two logo).Â Those meetings are always very inspiring, and usually result in all sorts of new ideas flying around and a flurry of activity in the days following.

Having non-work related hobbies really helps to keep me from spending too much time on work. Training for half marathons (I keep saying that one of these days I’ll do a full marathon–we’ll see about that), or just getting back in shape to do a century on my bike require quite a time commitment and keep me in shape and in top mental shape.

I suppose this is exactly the feeling that some companies try to encourage in their employees. They hire people who are really passionate about their work, give them the means and the freedom to do it, and hope they pour their heart into it. They just have to hope that their employees are able to keep themselves from burning out. That might be easier if you’re forced to work from an office environment, totally separate from home. On the other hand, being away from your family for longs periods of time eventually takes a toll on happiness and morale.

That’s a totally different beast from the kind of crunch that is rampant in the games industry. I define crunch as having to mandate long work hours (either explicitly or through peer pressure–which is more sublte and infinitely more evil). In one case, you’re so passionate about what you’re doing that you can’t wait to go back to work on Monday morning. In the other case, you’re still stuck to your desk come Monday morning because you were forced to work the weekend and get a build ready for some marketing demo. One is a very rewarding life, the other is soul-draining. One results in happy, ultra-productive people and the other degenerates into a death march, people leaving, and projects being even more delayed.

So, even with the February deadline looming, I want to take a few more hours these next few days and get back into the wrting swing of things. Besides, with the app coming up so soon, I should start thinking about announcing it soon! First I need to wrap up the Game Developer Magazine column due on Monday, but after that, I’ll try to start posting regular updates.

Until then, happy holidays to everybody. I hope you’re taking some time off, or at least doing what you really love.

A Day in the Life

High Moon Studios is an unusual company in the games industry. We’re applying agile methodologies for all of our development. My team in particular is using both Scrum (an agile management methodology) and Extreme Programming (an agile engineering methodology). And yes, that means we’re doing pair programming, test-driven development, and all the other often controversial practices. I expect that in a few years, these practices will be a lot more common than they are today. Continue reading →

Book Review: Pair Programming Illuminated

Pair programming really needs to be experienced to be fully appreciated. Just a few years ago, I loved my single office and I was completely against the idea of spending all my time programming with somebody else sitting at the same computer. Today I advocated using pair programming at work and I gladly gave up my office to work in a pair-programming lab alongside the whole team. Funny how things change.

Continue reading →